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REMARKS 



Minor amendments have been made to the specification. Claims 1, 7 - 8, 20, 26 - 27, 39, 
45 - 46, and 59 have been amended. Claims 60-61 have been added. No new matter has been 
introduced with these amendments or added claims, which are supported in the specification as 
originally filed. Claims 1, 7 - 8, 20, 26 - 27, 39, 45 - 46, and 58 - 61 are now in the application. 

I. Rejection Under 35 U.S.C. 5103(a) 

Paragraph 4 of 1he Office Action dated July 30, 2003 (hereinafter, "the Office Action") 
states that Claims 1,7-8, 20, 26 - 27, 39, 45 - 46, and 58 - 59 are rejected under 35 US.C. 
§1 03(a) as being unpatentable over Daly et aL (U. S. Patent 5,878,141) in view of Bezos et al, (U. 
S. Patent 6,029,141). This rejection is respectfully traversed with reference to the claims as 
amended herein. 

Paragraph 4 of the Office Action admits that Daly does not teach gathering context 
information, including this information in a payment protocol message, and so forth, and then 
states that Bezos teaches these limitations. Differences between the teachings of Bezos and 
Applicant's claimed invention will now be described to demonstrate that Bezos does not, in fact, 
teach Applicant's invention. 

In Bezos, a Uniform Resource Locator ("URL") conveys an associate/store identifier 
("ID"), product ID, and optionally a commission method ID, and is sent from a customer's 
browser via a request message to a merchant with whom the associate is enrolled. Upon 
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receiving this information (or upon receiving a purchase request for the product identified in the 
URL) at the merchant, the merchant credits the associate's account with a referral credit. 

A number of references in Bezos make clear that the merchant is responsible for this 
referral processing. In contrast. Applicant's invention uses a model where the merchant is not 
necessarily trusted. (Applicant's invention is described in more detail below*) References in 
Bezos to performing referral processing at the merchant include the following: 

• Col 2 ? lines 61 - 65, Software running on the merchant she then uses the 
information collected within the shopping cart to identify, and appropriately credit 
the account of, each associate that provided a corresponding referral." (emphasis 
added) 

Col. 7, lines 30 - 34, "A computer program 144 of the merchant Web site 106 uses 
this information ... to credit the sale (referral) to the associate ..." (emphasis 
added). Lines 43 - 45 of col. 7 are similar. 

♦ CoL % lines 4-5 state that the merchant identifies and credits the (referring) 
associate. 

* CoL 12, line 52 - col. 13, line 8 explain the processing that occurs in the computer 
program 144 on merchant Web server 132 when the customer clicks on a referral 
link. It is clear from this discussion that the parsing of the URL 5 and extraction of 
referral information contained therein, is performed by this merchant software. 

• CoL 13, lines 10 - 14 and lines 17 - 19 discuss the merchant handling associate 
referrals, using information the merchant has recorded in a shopping cart data 
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structure. See also col. 13, lines 31 - 34 and col. 15, lines 39 - 44 and 55 - 60 ? 
stating that the shopping cart stores information used to keep track of referrals. 
(According to reference number 152 of Fig. 1 and the text at col. 13, lines 35 - 37, 
the shopping cart is stored at the merchant Web site 106,) 
CoL 14, lines 64 - 67, stating "After processing a referral URL, the merchant Web 
server 132 sends the detail page 136 [identified in that URL] to the customer's 
Web browser 112 ..." 

Col 1 5, lines 61-62 also states "The merchant Web site includes credit generation 
software for calculating associate referral credit." 

This merchant-perforraed processing is according to Bezos' technique of including 
information in a URL, where the entity responsible for processing that URL is the merchant site. 
See, for example, col. 2, lines 1 - 3, explaining that the referral information "is transmitted to the 
merchant's site when a user (customer) clicks on the referral link" See also coL 8, lines 59 - 62, 
discussing the "URL-embedded referral information". 

In Applicant's invention, TV context information (that can subsequently be used for 
computing cotramssions) is sent from a consumer, through a merchant, to a bank (or the bank's 
gateway). This latter entity is referred to in the claims as a "payment processor". The TV 
context information is protected during these transmissions, using (for example) a digital 
signature. Therefore, the merchant can only forward this information but importantly, cannot 
modify it. This is in contrast to Bezos' technique of including referral information in a URL, as 
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shown in Fig- 4, where this URL-specified content is directed to the merchant (and is intended to 
be processed by the merchant)- Bezos thereby fails to protect the referral content from alteration 
by the merchant. 

The technique disclosed in Bezos, where the referral information is specified in a URL in 
the clear, is designed for a model where URL-specified content is statically embedded within the 
URL when imtiaUyjcreating the HTML content for a page from which the URL will be selectable 
by a user. See, for example: 

♦ Fig. 4, illustrating a static identification of product and associate IDs; 

• col. 10, lines 50 - 57 5 stating that an e-mail message will be sent to the associate 
(upon processing the associate's enrollment) to explain how the referral 
information is to be specified in "HTML documents with referral links", specifying 
a '"predefined format" of the URL into which the associate ID and product ID will 
be embedded; 

the "<H3>" line in Fig. 7, illustrating one of these URLs embedded into a Web 
page; 

col. 1 7, lines 38-41 (beginning "For each book you recommend, link to it us like 
this:")* reciting instructions that are provided to associates for creating these static 
links. Col. 1 0, lines 65 * 67 also refers to this text in Appendix A as conveying 
"linking instructions" to new associates; and 

col. 1 1, lines 1 - 19, describing the URL format for specifying referral links, and 
stating (in lines 16-19) that the associate can "begin to build" the content that will 
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contain this static referral syntax. 



The URL is invoked when the user wishes to view a product at the merchant's site. 
Applicant's invention, on the other hand, sends TV context information in a series of messages 
that corresponds to the consumer's payment for a transaction. A 4-party version and a 3-party 
version of this technique are defined, as will now be described. 



In the 4-party version of Applicant's invention, illustrated by the flows in Fig. 3, the 
issuing hank (or gateway; hereinafter "issuer") of the consumer's credit/debit card provides a 
signed token authorizing payment for a transaction, along with a digital signature that is computed 
in view of the TV context information the issuer has received from the consumer. See message 
flow 3 1 0 P where the TV context information is initially transmitted to the issuer, and message 
flows 315, 320, where the signed token and TV context information are transmitted from the 
issuer (through the consumer) to the merchant. 

Page 20, line 20 - p. 21, line 1 of Applicant's specification states that the message sent 
from the consumer to the issuer at 3 1 0 is digitally signed by the consumer's wallet program "to 
ensure that the TV context and other information cannot be altered". Page 22, limes 2-9 explain 
that the issuer verifies the digital signature on this message 3 10, and then creates and sends the 
signed token and TV context information in message 3 IS. The signature of this issuer is verified 
by the merchant (p. 22, lines 10-11), thereby ensuring that the transaction is authorized, but the 
signature prevents the merchant from altering any of the data in the signed authorization - 
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specifically, for purposes of the present discussion, from altering the TV context information (as 
explicitly stated on p. 22, lines 14-16). 



unchanged to the acquiring bank (or gateway; hereinafter "acquirer). See message flow 325, and 
the corresponding text at p. 22, lines 17 - 20. Upon receiving this message 325, the acquirer 
validates the signature on the token, and can then use the TV context information to allocate 
funds associated with the transactioa See p. 22, lines 20 - 22. 

Page 23, lines 3-7 also discusses this protection of the TV context information, stating 
that "[a)n important aspect of the present invention" is that any modification by the merchant 
would be detected by the acquirer, resulting in denial of payment to the merchant. 

In the 3-party version of Applicant's invention, illustrated by the flows in Fig. 4, the 
consumer is responsible for computing the signature that protects the TV context information 
from disclosure to the merchant. Accordingly, this signed data (including the TV context 
information) is sent from the consumer to the merchant (see message flow 410 and corresponding 
text on p. 24, lines 7-10), and when payment for the transaction has been authorized (message 
flows 41 5a, 415b, 420a, 420b), the merchant forwards the signed TV context information, 
unchanged, to the acquirer (see message flow 435 and corresponding text on p. 24, lines 23 - 24). 
As in the 4-party approach, the acquirer is responsible for validating the signature, and can then 
use the TV context information to allocate funds associated with the transaction. 
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Applicant's independent claims have been amended herein to more clearly specify 
limitations pertaining to the TV context information and its secure transmission. Applicant 
respectfully submits that independent Claims 1, 20, and 39, as amended herein, are patentable 
over the cited references. Therefore, Applicant's dependent claims are patentable over the cited 
references as well. The Examiner is therefore respectfully requested to withdraw the § 103(a) 
rejection 

II. Conclusion 

Applicant respectfully requests reconsideration of the pending rejected claims, withdrawal 
of all presently outstanding rejections, and allowance of all remaining claims at an early dale. 

Respectfully submitted, 




Marcia L. Doubet 
Attorney for Applicant 
Reg. No. 40,999 
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